最近看到一本書
Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software
以前在DDD活動上, 聽到這協作方法.

其中書本第一章有講到Telling stories的好處
我將前兩章節的內容, 做成投影片簡單的跟部門分享
Slide - Storytelling & Domain Stroytelling
這幾天來以文字的形式跟各位分享

前言

常見的會議情況

情境1

在專案還是產品Kickoff時,
以會議報告的形式進行討論, 真正具有價值的時間很少, 幾乎都浪費掉了
然後就會以沒結論的方式, 說下次再召開會議繼續.

情境2

會議中有人報告時, 其實很多人不清楚, 這報告的內容主要是在解決什麼問題?
甚至很多某些領域下的專有名詞

情境3

會議上, 直接對著畫面跟操作動線進行爭論
直接針對細節做深入討論
有的則是直接在會議上討論, 資料庫或表格設計什麼的.

分析

以下是我的見解

• 情境1
  會議幾乎都是聽PM或企劃在從畫面草稿跟行銷手段在介紹
  也許對於創新產品沒問題,
  但若是針對既有問題或需求, 從畫面草稿跟行銷企劃, 很難讓所有與會人員都能理解完整的問題域與相關的業務流程

• 情境2
  其實也是跟上面一樣, 所有與會人員都能理解完整的問題域與相關的業務流程.
  因為大家的背景或專長可能就都不同

常見狀況: 有些人講一講會講到API或Table... 與會人員一半都是管理跟企劃行銷, 根本不知道在講什麼

• 情境3
  一開始就針對細節展開, 很容易產生爭執
  這是因為每個人對問題的認知或理解程度, 都不同
  自然而然想像出來的也是不同

蕭煌奇- 你是我的眼
眼前的黑不是黑 你說的白是什麼白
人們說的天空藍 是我記憶中那團白雲背後的藍天

書上第一篇講到一些觀點

conversations cannot be adeqquately replaced by written, formal specifications.
attempts to do so have even widened the gap between business and software development.

交談溝通並不能完全取代書寫與正式規範,
如果只靠交談溝通其實只會更加地讓業務與軟體開發人員之間的gap更深.

consider software development approaches like agile, Domain-Drivent Design or BDD.
these philosophies foucs on feedback and stackeholder involvement.
nevertheless, making great bussiness software is hard, but rarely is this because of technical problems.
because software developers need to understand how the day-to-day busniess operates.
they need to become domain experts themselves - not for the whole domain but at least for the part they build software for.

像是Agile、DDD或是BDD, 更鼓勵的是回饋還有stackholder的參與.
構建出複雜的商業服務頗難, 但難的部份幾乎不是技術上的問題.
更多的是業務問題, 開發人員需要了解日常業務的運作方式.
試圖讓自己也成為自己負責部份的領域專家.

書上也引述一段Alberto Brandolini的話

it's developers (mis)understanding, not expert knowledge, that gets released in production.

發布出去的軟體其認知是開發人員的理解(or誤解), 而不是領域的專業知識.
講白話點, 是開發人員對規格書的理解而已.

根據上面我自己的分析, 加上書上這段論點.
如果要在溝通協作上, 更有效率的討論, 對領域與問題的共同認知是必要的.
怎快速建立共同認知呢?
這時候說書人說故事就是個很簡單又有成效的方法了

說故事前, 又得召集會議?
其實以前或是現在日常還蠻多活動, 不是以會議形式展開的,
而是以類似小團體, 彼此圍成圈, 一起討論的形式
像是Campfires, 營火夠大就能圈多人, 小營火就圈少點人
中間的營火則是大家目光聚集的對象
常常這類活動也會有主持人或是說書人, 在旁邊講述事情
這樣的形式, 大家都能很快地融入其中

上圖大家都跟著主持人做起一樣的動作, 因為都聚焦在主持人身上
事情有需要準備一堆說明或練習, 才能帶動大家一起做出一致的動作嘛?
我想不必吧!?

上圖這張我想表示的是, 小的營火聚會
能聚集一些來自不同背景、膚色、性別的人在一起, 也能愉悅的溝通討論

但! 凡事總有But!
開會就不是這樣阿? 老闆就想要聽到結論阿!!
But上面的開會形式就能有效率地在一次會議中得到結論嘛?
我想給的台詞大多還是長官, 我們會後再招開小會議討論,下次給結論
但這另開的小會議, 比較多都是要開發團隊給個人天時程...
開發團隊跟業務之間的gap依然存在, 需要時間跟經驗來消弭.
且搞不好下次長官們想法又稍微變化了, 這順序又要重複Loop
就回到情境1了

結論出來後...
開發團隊: X的, 上面就只會要我們給時程, 怎麼做我們都不清楚
業務單位: x的, 開發團隊是不是能力不夠阿, 怎我們給了厚厚的文件, 他們每次都還是做錯

Campfires只是個示意, 描述的是必要的開發團隊與Stakeholder或是業務單位
聚在一起, 請Stakeholder或是業務單位用說故事的方式.
開發團隊無法直接接觸真實客戶也無訪. 反正有業務單位或窗口

Story Telling

說故事 總不會有人這樣說書吧?

小明進到市場, 如果看到低於1斤20$的橘子則買一斤. 看到吐司有特價則買一條.
三英打呂布, 如果關羽擋住呂布刺擊, 則張飛與劉備則從左右進行砍擊.

描述的都是過去的事實;
且描述的事實順序, 正好就是業務行為的順序與時間線上的對應關係

小明進到市場, 今天是冬季且快關門了,買了1斤18$的橘子, 買了一條特價的吐司.
在虎牢關, 三英正在打呂布, 關羽擋住了呂布的刺擊, 同時張飛與劉備發現呂步, 側門大開, 則立刻從左右進行砍擊.

敏捷開發宣言

前面扯一堆幹話, 還是沒講到怎樣的有效討論
但這裡是舉另一個論點來講 (又繼續幹話了)
敏捷開發宣言裡說到

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation

Responding to change over following a plan

Individuals and interactions over processes and tools
成員跟互動 比起 工具還有做抽象流程, 來的重要
這的重要指的是效率, 呼應我們主題有效的討論

Customer collaboration over contract negotiation
與客戶協作討論 比起 文件合約的協商, 來的重要.
但我想轉個角度想成, 傳統的SA或PM文件, 公司都是希望能一次到位.
但等到這文件確定寫的是符合客戶所需的, 大概也是來來回回數次修改跟協商確認後的版本了.
但也沒說這不重要, 但與其這樣來來回回, 不如找客戶一起當場確認修改.
這後面會說明.

簡易有效的討論

根據宣言可以發現要是成員們一起互動, 與客戶一起協作討論,
想必會比較能省去初期就投入一堆時間寫文件

如果可以, 主要是邀請Domain expert來對著開發人員們講解故事

這張圖我想表達的是
用說故事的方式傳達業務與領域知識, 比起用一堆流程圖來傳達,
更為簡單好懂又不費太多功夫

當然文件還是得補上的, 只是可以在事後追加進去.
先讓開發人員的理解, 足以理解/貼合業務流程所需.

下一篇來寫Domain Storytelling這方法與對應適當的工具